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Defining and Using Metadata with YANG 


Abstract 
This document defines a YANG extension that allows for defining 
metadata annotations in YANG modules. The document also specifies 
XML and JSON encoding of annotations and other rules for annotating 
instances of YANG data nodes. 
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Internet Standards is available in Section 2 of RFC 7841. 
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and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7952. 
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Les 


Introduction 


There is a need to be able to annotate instances of YANG [RFC7950] 
data nodes with metadata. Typical use cases are as follows: 


o Complementing regular data model information with 
instance-specific metadata, comments, etc. 


o Providing information about the rendering of data in user 
interfaces. 


o Deactivating a subtree in a configuration datastore while keeping 
the data in place. 


o Network management protocols often use metadata annotations for 
various purposes in both operation requests and responses. For 
example, the <edit-config> operation in the Network Configuration 
Protocol (NETCONF) (see Section 7.2 of [RFC6241]) uses annotations 
in the form of XML attributes for identifying the location ina 
configuration datastore and the type of the operation. 


However, metadata annotations could potentially lead to 
interoperability problems if they are used in an ad hoc fashion by 
different parties and/or without proper documentation. A sound 
metadata framework for YANG should therefore satisfy these 
requirements: 


1. The set of annotations must be extensible in a decentralized 
manner so as to allow for defining new annotations without 
running the risk of collisions with annotations defined and used 
by others. 


2. The syntax and semantics of annotations must be documented, and 
the documentation must be easily accessible. 


3. Clients of network management protocols such as NETCONF [RFC6241] 
or RESTCONF [RESTCONF] must be able to discover all annotations 
supported by a given server and identify each of them correctly. 


4. Annotations sent by a server should not break clients that don’t 
support them. 


This document proposes a systematic way to define metadata 
annotations. For this purpose, the YANG extension "annotation" is 
defined in the module "ietf-yang-metadata" (Section 7). Other YANG 
modules importing this module can use the "annotation" statement for 
defining one or more annotations. 
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The benefits of defining the metadata annotations in a YANG module 
are the following: 


o Each annotation is bound to a YANG module name and namespace URI. 
This makes its encoding in instance documents (both XML and JSON) 
straightforward and consistent with the encoding of YANG data node 
instances. 


o Annotations defined in IETF Standards Track documents are 
indirectly registered through IANA in the "YANG Module Names" 
registry [RFC6020]. 


o Annotations are included in the data model. YANG compilers and 
tools supporting a certain annotation can thus take them into 
account and modify their behavior accordingly. 


o The semantics of an annotation are defined in the "description" 
and "reference" statements. 


o An annotation can be declared as conditional by using the 
"if-feature" statement. 


o The type of each annotation is explicitly specified; any YANG 
built-in or derived type that is available for leaf or leaf-list 
data nodes may be specified for annotations as well. 


In the XML encoding, XML attributes are a natural instrument for 
attaching annotations to data node instances. This document 
deliberately adopts some restrictions in order to remain compatible 
with the XML encoding of YANG data node instances and limitations of 
XML attributes. Specifically, 


o annotations can only be scalar values. 


o annotations cannot be attached to a whole list or leaf-list 
instance, only to individual list or leaf-list entries. 


Due to the rules for YANG extensions (see Section 6.3.1 in 
[RFC7950]), annotation definitions posit relatively weak conformance 
requirements. The alternative of introducing a new built-in YANG 
statement for defining annotations was considered, but it was seen as 
a major change to the language that is inappropriate for YANG 1.1, 
which was chartered as a maintenance revision. After evaluating 
real-life usage of metadata annotations, it is conceivable that such 
a new built-in statement might be added in a future revision of YANG. 
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2. Terminology 
2.1. Key Words 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
2.2. Terms Defined in Other Documents 
The following terms are defined in [RFC6241]: 
o capability 
o client 
o datastore 
o message 
Oo protocol operation 
o server 
The following terms are defined in [RFC7950]: 
o action 
o anydata 
o anyxml 
o built-in type 
o container 
o data model 
o data node 
o data tree 
o derived type 
o extension 


o leaf 
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o leaf-list 
o list 
o module 
o Remote Procedure Call (RPC) input and output 


The following terms are defined in [XML-INFOSET]: 


(0) 


(0) 


(0) 


attribute 


document 


element 


The following terms are defined in [XML-NAMES]: 


(0) 


(0) 


(0) 


(0) 


local name 
namespace name 
prefix 


qualified name 


The following terms are defined in [RFC7159]: 


o array 
o member 
o object 
o primitive type 
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2.3. Namespaces and Prefixes 
In the following text, XML element names and YANG extension 


statements are always written with explicit namespace prefixes that 
are assumed to be bound to URI references as shown in Table 1. 


http://example.org/example-last—modified | 
urn:ietf:params:xml:ns:yang:ietf-yang-metadata | 
http://relaxng.org/ns/structure/1.0 | 
Table 1: Used Namespace Prefixes and Corresponding URI References 


2.4. Definitions of New Terms 


o annotation: a single item of metadata that is attached to YANG 
data node instances. 


o metadata: additional information that complements a data tree. 


o metadata object: an object in JSON encoding that contains all 
annotations attached to a given data node instance. 
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3. Defining Annotations in YANG 


Metadata annotations are defined by the YANG extension 


"md:annotation". This YANG language extension is defined in the 
module "ietf-yang-metadata" (Section 7). 
Substatements of "md:annotation" are shown in Table 2. They are all 


core YANG statements, and the numbers in the second column refer to 
the corresponding section in [RFC7950] where each statement is 


described. 
+-------------- +--------------------- +------------- + 
| substatement | section in RFC 7950 | cardinality | 
+-------------- +--------------------- +------------- + 
| description | 7.21.3 Eorsi 
if-feature 7.20.2 O..n 
reference Tez tss Orne 
| status [| Fees 2 | isa | 
| type | 7.6.3 ie | 
| units ere |) sed | 
+-------------- +--------------------—- +------------- + 
Table 2: Substatements of "md:annotation" 
An annotation carries a single value. The "type" substatement, which 


MUST be present, takes as an argument the name of an existing 
built-in or derived type, and the value of the annotation MUST match 
this type. See Section 7.4 of [RFC7950] for details. 


An annotation can be made conditional by using one or more 
"if-feature" statements; the annotation is then supported only by 
servers that advertise the corresponding feature. 


The semantics and usage rules for an annotation SHOULD be fully 
specified in "description", "reference", and "units" statements. 


An annotation MUST NOT change the data tree semantics defined by 
YANG. For example, it is illegal to define and use an annotation 
that allows for overriding uniqueness of leaf-list entries. 


The "status" statement can be used exactly as it is used for YANG 
data nodes. 


A YANG module containing one or more "md:annotation" statements 
SHOULD NOT be used for defining data nodes or groupings. Also, 
derived types, identities, and features SHOULD NOT be defined in such 
a module unless they are used by the definitions of annotations in 
that module. 
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3.1. Example Definition 
The following module defines the "last-modified" annotation: 


module example-last-modified { 
namespace "http://example.org/example-last-—modified"; 
prefix "elm"; 
import ietf-yang-types { 
prefix "yang"; 
} 
import ietf-yang-metadata { 
prefix "md"; 
} 
md:annotation last-modified { 
type yang:date-and-time; 
description 
"This annotation contains the date and time when the 
annotated instance was last modified (or created) ."; 


4. Using Annotations 


By advertising a YANG module in which a metadata annotation is 
defined using the "md:annotation" statement, a server indicates that 
it is prepared to handle that annotation according to the 
annotation’s definition. That is, an annotation advertised by the 
server may be attached to an instance of a data node defined in any 
YANG module that is implemented by the server. 


Depending on its semantics, an annotation may have an effect only in 
certain data trees and/or on instances of specific types of data 
nodes. 


A client MUST NOT add a specific annotation to data node instances if 
the server didn’t advertise it. 


Due care has to be exercised when introducing annotations in network 
management systems in order to avoid interoperability problems and 
software failures caused by a client that does not understand the 
annotations’ semantics. Generally, it is safe for a server to use 
annotations in the following cases: 


o An annotation is an integral part of a built-in or negotiated 
protocol capability. 


o An annotation contains auxiliary information that is not critical 
for protocol operation. 
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o The client explicitly asks the server, e.g., via a parameter of a 
protocol operation request, to include an annotation in the 
response. 


5. The Encoding of Annotations 


XML attributes are a natural choice for encoding metadata in XML 
instance documents. For JSON [RFC7159], there is no generally 
established method for encoding metadata. This document thus 
introduces a special encoding method that is consistent with the JSON 
encoding of YANG data node instances as defined in [RFC7951]. 


5.1. XML Encoding 


Metadata annotations are added to XML-encoded instances of YANG data 
nodes as XML attributes according to these rules: 


o The local name of the attribute SHALL be the same as the name of 
the annotation specified in the argument of the corresponding 
"md:annotation" statement. 


o The namespace of the attribute SHALL be identified by the URI that 
appears as the argument of the "namespace" statement in the YANG 
module where the annotation is defined. It is RECOMMENDED that 
the prefix specified by the "prefix" statement in the same module 
be used in the qualified name of the attribute. 


o The attribute value SHALL be encoded in the same way as the value 
of a YANG leaf instance having the same type; see Section 9 of 
[RFC7950]. 


For example, the "last-modified" annotation defined in Section 3.1 
may be encoded as follows: 


<foo xmlns:elm="http://example.org/example-last-modified" 
elm: last-modified="2015-09-16T10:27:35+02:00"> 


</foo> 
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5.2. JSON Encoding 


The JSON metadata encoding defined in this section has the following 
properties: 


1. The encoding of YANG data node instances as defined in [RFC7951] 
does not change. 


2. Namespaces of metadata annotations are encoded in the same way as 
namespaces of YANG data node instances; see [RFC7951]. 


5.2.1. Metadata Object and Annotations 


All metadata annotations assigned to a YANG data node instance are 
encoded as members (name/value pairs) of a single JSON object, 
henceforth denoted as the metadata object. The placement and name of 
this object depend on the type of the data node as specified in the 
following subsections. 


The name of a metadata annotation (as a member of the metadata 
object) has the following ABNF syntax [RFC5234], where the production 
for "identifier" is defined in Section 14 of [RFC7950]: 


annotation-name = identifier ":" identifier 


where the left identifier is the name of the YANG module in which the 
annotation is defined and the identifier on the right is the name of 
the annotation specified in the argument of the corresponding 
"md:annotation" statement. 


Note that unlike member names of YANG data node instances in JSON 
encoding (see Section 4 in [RFC7951]), for annotations the explicit 
namespace identifier (module name) must always be present. 


The value of a metadata annotation SHALL be encoded in exactly the 
same way as the value of a YANG leaf node having the same type as the 
annotation; see Section 6 of [RFC7951]. 
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5.2.2. Adding Annotations to anydata, container, and list Entries 


For a data node instance that is encoded as a JSON object (i.e., a 
container, list entry, or anydata node), the metadata object is added 
as a new member of that object with the name "@". 


Examples: 


o "cask" is a container or anydata node: 


"cask": { 
wars { 
"example-last-—modified:last-—modified": 
"2015-09-16T10:27:35+02:00" 
}, 


o "seq" is a list whose key is "name"; annotation "last-modified" is 
added only to the first entry: 


"seq": [ 

{ 

wars { 
"example-last-—modified:last-—modified": 
"2015-09-16T10:27:35+02:00" 

}, 
"name": "one", 

}, 

{ 
"name": "two", 


5.2.3. Adding Annotations to anyxml and leaf Instances 


For an anyxml or leaf instance, the metadata object is added as a 
sibling name/value pair whose name is the symbol "@" concatenated 
with the name of the leaf or anyxml member that is being annotated. 
The namespace part (module name) is included if and only if it is in 
the name of the annotated member. 
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Examples: 


o "flag" is a leaf node of the "boolean" type defined in module 
"foo", and we assume that the namespace name has to be expressed 
in its JSON encoding: 


"foo:flag": true, 
"@foo:flag": { 
"example-last-—modified:last-—modified": 
"2015-09-16T10:27:35+02:00" 


o "stuff" is an anyxml node: 


"stuff": [1, null, "three"], 
"@stuff": { 
"example-last—modified:last-—modified": 
"2015-09-16T10:27:35+02:00" 


5.2.4. Adding Annotations to leaf-list Entries 


For a leaf-list entry, which is represented as a JSON array with 
values of a primitive type, annotations may be assigned to one or 
more entries by adding a name/array pair as a sibling of the 
leaf-list entry, where the name is the symbol "@" concatenated with 
the name of the leaf-list that is being annotated, and the value is a 
JSON array whose i-th element is the metadata object with annotations 
assigned to the i-th entry of the leaf-list entry, or null if the 
i-th entry has no annotations. 


Trailing null values in that array, i.e., those following the last 
non-null metadata object, MAY be omitted. 


For example, in the following leaf-list instance with four entries, 
the "last-modified" annotation is added to the second and third 
entries in the following way: 


"bibliomod:folio": [6, 3, 7, 8], 
"@bibliomod:folio"™: [ 
null, 
{ "example-last-—modified:last-—modified": 
"2015-06-18T17:01:14+02:00" 
hy 
{ "example-last-—modified:last-—modified": 
"2015-09-16T10:27:35+02:00" 
} 
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6. 


Representing Annotations in DSDL Schemas 


[RFC6110] defines the standard mapping of YANG data models to 


Document Schema Definition Languages (DSDL) [1S0.19757-1]. This 
section specifies the mapping for the extension statement 
"md:annotation" (Section 7), which enables validation of XML instance 


documents containing metadata annotations. 


The first step of the DSDL mapping procedure, i.e., the 
transformation of the YANG data model to the hybrid schema (see 
Section 6 in [RFC6110]), is modified as follows: 


1. If the data model contains at least one "md:annotation" 
statement, then a RELAX NG [1S0.19757-2] named pattern definition 
MUST be added as a child of the root <rng:grammar> element in the 
hybrid schema. It is RECOMMENDED to use the name 
"_yang_metadata__" for this named pattern. 


2. A reference to the named pattern described in item 1 MUST be 
included as a child of every <rng:element> pattern that 
corresponds to an anydata, container, leaf, leaf-list, or list 
data node. 


3. Every metadata annotation definition in the form 
md:annotation ARGUMENT { 


} 
is mapped to the following RELAX NG [ISO.19757-2] pattern: 


<rng:optional> 
<rng:attribute name="PREFIX:ARGUMENT"> 


</rng:attribute> 
</rng:optional> 


where PREFIX is the prefix bound to the namespace URI of the YANG 
module that contains the "md:annotation" statement. The above 
pattern SHALL be inserted as a child of the named pattern 
described in item 1. 


4. Substatements of "md:annotation" SHALL be mapped to children of 
the "rng:attribute" pattern exactly as described in Section 10 of 
[RFC6110]. 
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For example, the named pattern (item 1), when constructed only for 
the "last-modified" annotation, will have the following definition: 


<rng:define name="__yang_metadata__"> 
<rng:optional> 
<rng:attribute name="elm:last-—modified"> 
<rng:ref name="ietf-yang-types__date-and-time"/> 
</rng:attribute> 
</rng:optional> 
</rng:define> 


Every "rng:element" pattern that corresponds to an anydata, 
container, leaf, list, or leaf-list data node will then contain a 
reference to the above named pattern; for example: 


<rng:element name="foo:bar"> 
<rng:ref name="__yang_metadata__"/> 


</rng:element> 


Note that it is not necessary to use such a reference for 
"rng:element" patterns corresponding to anyxml data nodes because 
they already permit any XML attributes to be attached to their 
instances. 


The second step of the DSDL mapping procedure, i.e., the 
transformation of the hybrid schema to RELAX NG [1S0.19757-2], 
Schematron [1S0.19757-3], and Document Semantics Renaming Language 
(DSRL) [1S0.19757-8] schemas, is unaffected by the inclusion of 
"md:annotation". 
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7. Metadata YANG Module 
<CODE BEGINS> file "ietf-yang-metadata@2016-08-05.yang" 
module ietf-yang-metadata { 
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-metadata"; 
prefix "md"; 


organization 
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 


contact 
"WG Web: <https://datatracker.ietf.org/wg/netmod/> 


WG List: <mailto:netmod@ietf.org> 


WG Chair: Lou Berger 
<mailto:lberger@labn.net> 


WG Chair: Kent Watsen 
<mailto:kwatsen@juniper.net> 


Editor: Ladislav Lhotka 
<mailto:lhotka@nic.cz>"; 


description 
"This YANG module defines an ’extension’ statement that allows 
for defining metadata annotations. 


Copyright (c) 2016 IETF Trust and the persons identified as 
authors of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or 
without modification, is permitted pursuant to, and subject to 
the license terms contained in, the Simplified BSD License set 
forth in Section 4.c of the IETF Trust’s Legal Provisions 
Relating to IETF Documents 
(http://trustee.ietf.org/license-info). 


This version of this YANG module is part of RFC 7952 


(http://www. rfc-editor.org/info/rfc7952); see the RFC itself 
for full legal notices."; 
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revision 2016-08-05 { 
description 
"Tnitial revision."; 
reference 
"RFC 7952: Defining and Using Metadata with YANG"; 
} 


extension annotation { 
argument name; 


description 
"This extension allows for defining metadata annotations in 
YANG modules. The ‘/md:annotation’ statement can appear only 


at the top level of a YANG module or submodule, i.e., it 
becomes a new alternative in the ABNF production rule for 
"body-stmts’ (Section 14 in RFC 7950). 


The argument of the ’/md:annotation’ statement defines the name 
of the annotation. Syntactically, it is a YANG identifier as 
defined in Section 6.2 of RFC 7950. 


An annotation defined with this ’extension’ statement inherits 
the namespace and other context from the YANG module in which 
it is defined. 


The data type of the annotation value is specified in the same 
way as for a leaf data node using the ‘type’ statement. 


The semantics of the annotation and other documentation can be 
specified using the following standard YANG substatements (all 
are optional): ’description’, 'if-feature’, 'reference’, 
‘status’, and ’units’. 


A server announces support for a particular annotation by 
including the module in which the annotation is defined among 
the advertised YANG modules, e.g., in a NETCONF <hello> 
message or in the YANG library (RFC 7950). The annotation can 
then be attached to any instance of a data node defined in any 
YANG module that is advertised by the server. 


XML encoding and JSON encoding of annotations are defined in 
RFC 7952."; 


<CODE ENDS> 
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8. 


IANA Considerations 


This document registers a URI in the "IETF XML Registry" [RFC3688]. 
Following the format in RFC 3688, the following registration has been 
made. 


URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata 
Registrant Contact: The NETMOD WG of the IETF. 


XML: N/A, the requested URI is an XML namespace. 


This document registers a YANG module in the "YANG Module Names" 
registry [RFC6020]. 


Name: ietf-yang-metadata 

Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-metadata 
Prefix: md 

Reference: RFC 7952 


Security Considerations 


This document introduces a mechanism for defining metadata 
annotations in YANG modules and attaching them to instances of YANG 
data nodes. By itself, this mechanism represents no security threat. 
Security implications of a particular annotation defined using this 
mechanism MUST be duly considered and documented in the annotation’s 
definition. 


An annotation SHOULD be subject to the same or stricter access 
control rules as the data node instance to which the annotation is 
attached. It is RECOMMENDED that security-sensitive or privacy- 
sensitive data be modeled as regular YANG data nodes rather than 
annotations. 
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